@cartermp, what loop? The only loops I see are those that are used to create expression trees during the precomputation. There are no loops inside the compiled delegates.

In this case I'm referring to a loop like this: https://github.com/dotnet/fsharp/pull/9784/files#diff-54378f53a8612b2adf50a6efb115ba5aR134

The compiler rewrites this to use an enumerator no matter which kind of for loop you use, see:

current impl
for x = 0 to loop

Rewriting it to a while loop and manually bumping the indexer will remove that like so but it's unlikely to matter much from a perf standpoint. Just kind of weird that trivially changing the for loop had no effect when it usually does.

Yeah, I'd be all for altering the loop were this happening inside of the delegate. Don't think it matters at all during prep stage.

In hot paths it matters for ints, it's about 4x slower when it becomes an enumeration. That may not matter much here, though. There's an issue open to better optimize this, the example from @cartermp will help there.

This func is compileUnionCaseConstructorFunc ... it should not happen frequently.

@kerams if you want to further improve performance (by 6-7 (on netcore 3.1) times for the "get all properties" case you can modify the expression to initialize the array in reverse order to avoid array bounds check.

I have a method added to your benchmark from the previous PR and results laying around at home that I can post next week if it is of interest.
But it might be regarded as a micro optimization and not too relevant here since one might expect Expression.InitArray to be as fast as possible

and it might be a flaw in the benchmark code

@Daniel-Svensson, are you saying

var a = int[5];
a[0] = 0;
a[1] = 0;
a[2] = 0;
a[3] = 0;
a[4] = 0;

is 6 times slower than

var a = int[5];
a[4] = 0;
a[3] = 0;
a[2] = 0;
a[1] = 0;
a[0] = 0;

??

Apologies for using 'the other sharp'.

@kerams actually I belive I must have a bug in my fsharp (cannot check it this week), it was a quick hack late before bedtime.
If the length is unknown to the jit the reverse order is much faster but thinking more about it i would not expect such large improvements but only double digit percentage. There are many such "hacks" in the runtime